The following is a list of the known problems in this release of ODF. This includes the Radar Bug Tracking number,
the bug title, details of the problem, and, in some cases, a workaround.
1311027
ODF and Threads/Offscreen bitmaps
I am writing an ODF based part that uses an offscreen bitmap that is drawn using threads. I seem to be having a problem with graphic contexts with the multiple threads. Explain how I can have graphic contexts safely in a threaded environment.
You can only create and use a graphic context and use it for a short amount of time. You can't yield while you have one active; you must exit the scope of your context before yielding.
1339399, 1339400
FW_CBitmap::ChangeBitmap parameters
FW_CBitmap::ChangeBitmap should have a palette parameter.
The bScale parameter with an image is not necessary.
1342662
Holding down Cmd-z undoes once, but menu flashes repeatedly
The menu bar flashes repeatedly as if Undo was chosen many times, but Undo is performed only once.
1352622
Casting problem in FW_CAcquiredODxxxx with STL
ODFContainer's Content.cpp won't compile in CW8 if any of the CW8
STL header files are included. This makes it difficult to use STL containers
as part of the content model for an embedding part, since PartMaker uses
ODFContainer as the template for embedding parts.
The problem is in the following lines in CBaseContent::RedrawProxies():
The template class that defines FW_CAcquiredODShape,
FW_TAcquiredODRefCntObject, declares two operator!=() functions, neither of
which handles a void* operand automatically. When an STL header file is
included, the compiler tries to bind the comparison to STL's global
operator!=() defined in STL's <function.h>, which generates a compiler error
about incompatible operands.
The local fix is to replace the comparison with
if (updateShape != (ODShape*) NULL)
or, for those who prefer the newer cast style
if (updateShape != static_cast<ODShape*>(NULL))
This matches one of the operator!=() defined by
FW_TAcquiredODRefCntObject<ODShape>, which forces the compiler to select the
correct operator!=(), and everything compiles.
1353968
Mac and Windows inconsistent about use of dash style vs. pattern
When ODF renders a geometric shape, it uses different logic on Windows and the Mac to decide whether to use the ink's dash style or its pattern.
- On the Mac, the dash style is used if the pen size is 1 pixel, otherwise the pattern is used.
- On Windows, the dash style is used (regardless of the pen size) unless the dash style is solid line; in that case, the pattern is used.
1365702
Text rendering in offscreen bitmap crashes
When I try to render a piece of text into an offscreen bitmap context, and
part of the text is outside the bounds of the context, my part crashes. If
I check for "contextBounds.Contains(textBounds)" before trying to render,
I don't get a crash.
There is misbehavior if the context is smaller than a single character. This is a Quickdraw bug when drawing text offscreen. The workaround is to check if the context boundary contains the text before drawing it.
1366257
FW_OFile::GetFileHandle should not return a pointer
FW_OFile::GetFileHandle returns a pointer to an FW_PlatformFileHandle. It should just return the FW_PlatformHandle, not a pointer. (This method can't be changed now, or it will break compatibility.)
1367091
FW_CBitmap::GetColor doesn't return the right color on 68K
1369783
FW_CTextBoxShape and italic
When I have a large font italicized and right-justified, the FW_CTextBoxShape tends to cut off some of the last letter.
1371233
FW_CPattern needs FW_BitPattern accessor
After creating a FW_CPattern to represent my bit pattern, I cannot get the bit pattern back
from the object in order to store it somewhere else. This means that I have to keep around my
own bit pattern representation of all the FW_CPatterns I'm using.
1375538
FW_CGraphicContextGX is slow the first time
The ODF FW_CGraphicContextGX class constructor is *very* slow the first time the class is
instantiated. There is a perceptible delay before the first GX shape is drawn. The delay seems to occur
only the first time after a reboot.
The first time GX is actually used, it "really" initializes. I guess this is to speed up load times when it is customary to EnterGraphics and InitPrinting at launch. The workaround is to create a FW_CGraphicContextGX early in the part's lifetime so that this delay is associated with launch rather than sluggish drawing.
1377599
Resources are still loaded in the application heap in FW_PResourceFile::GetResourceHandle.
1378789
Menu id assignment has builtin limit
When menus are first created, they are assigned a menu id of 255, which is the unattached value. When a menu is attached
to the menu bar it is assigned the next unused menu id. The variable fNextMenuID contains the next unused menu id, and
it is simply incremented on each assignement. If fNextMenuID reaches 255 no more menu ids can be assigned. A part that
does a lot of attaching and detaching of menus could hit this limit.
1382638
Window refcon conflict
When ODF goes to add a facet it checks and uses the window's refcon. The refcon is used for determining the existence of shareable windows. Frameworks like PowerPlant use the window's refcon to keep track of their windows. The problem is that, in the application container world, facets are added to windows created by the application. ODF needs to be modified to not depend on refcons of windows it does not create.
1384628
MenuBar::GetItemString locale info is not usable for comparing strings
This is actually an OpenDoc bug. The string returned from GetItemString has the following locale: (-1, 0) for System script,
and (script, 0) for other scripts. The language code is always 0. The effect of this bug is that if you get a string from a menu
and compare it with another string, they won't match because the locales are different. This is particularly a problem with
Font menus containing font names in other scripts.